(1) Field of the Invention
This invention relates to communication networks. More precisely, it pertains to the problem of transmitting signaling messages through address translation devices such as NAT (“Network Address Translation”) devices.
(2) Description of Related Art
Current communication networks enable the establishment of communication sessions by means of signaling protocols such as H.323, MGCP (Media Gateway Control Protocol) or SIP (Session Initiation Protocol) and SDP (Session Description Protocol).
This SIP protocol is defined by RFC 3261 published by the IETF (Internet Engineering Task Force), and its dual purpose is:                to allow two parties to be brought into contact,        to enable the negotiation of the characteristics of the session to be established (video bitrate, which encoder (CODEC to use, etc.), via the SDP protocol.        
The negotiation of session characteristics is specified by RFC 3264, entitled “SDP offer/answer model”).
A calling party that wishes to call another party may send a signaling message (“Invite”) to a signaling element, known as a “proxy”, containing its personal address, the physical address of its terminal (or, more generally speaking, a client), and the personal address of the party being called. The signal element has means (the “registrar”) for matching the personal address of the party being called with the physical address of the corresponding terminal. This matching allows the signaling message to be routed to the party being called.
If that party accepts the call, the party responds with new signaling messages that include the physical address of the terminal or client. In this manner, as both terminals know the physical address of the other party, they may establish an IP (Internet Protocol) connection for transmitting data (voice, video, etc.)
However, a problem arises with address translation devices, known as NAT (“Network Address Translation”) or NAPT (“Network Address Port Translation”) devices, which are defined in RFC 1631, “The IP Network Address Translator”, and in RFC 3022 “Traditional IP Network Address Translator (Traditional NAT)”. These devices are designed to interface a first network (typically, a private network) with a second network (such as the public Internet network).
The devices (terminals) of the first network have physical IP addresses whose validity is limited to that first network. When they wish to establish communications with devices located outside that first network, the address translation device assigns them a temporary second address, valid for the second network, and saves the association between the client's first and second addresses.
The NAT address translation device therefore modifies the messages transmitted between the two communication networks on the fly, by:                converting the terminals' first addresses into second addresses, within the IP headers of the outgoing messages, i.e. those being sent from the first network to the public second network, and by        converting the terminals' second addresses into first addresses, within the IP headers of the incoming messages, i.e. those being sent from the second network to the first network.        
An address translation device, i.e. a NAT device, therefore possesses a table used to match up the first and second addresses. These match-ups are temporary, and are deleted when the connection or session is terminated. These associations or match-ups are conventionally known as “binding”.
A problem therefore arises when SIP/SDP signaling messages (or H.323 or others) traverse address translation devices. This problem is known as “NAT traversal”.
Signaling protocols, such as SIP and SDP, are considered application protocols. The SIP/SDP protocol, for example may be transmitted via the TCP or UDP protocol, which themselves are located above IP in the protocol stack. An SIP message is therefore, in reality, a succession of parameters enclosed within a TCP or UDP message, which is itself enclosed within an IP message.
NAT address translation devices only edit the parameters found within the IP layer, leaving the parameters found within the higher-up layers intact.
In other words, the physical addresses contained within the SIP and SDP messages are not edited by the address translation devices, unlike the addresses contained within the IP headers.
As a result, the recipient of the signaling message (the client being called) will only know the first address of the calling client. However, as this address is only meaningful within the first network, no communication session can be established.
As this problem is well known, numerous solutions have been advanced to resolve it. There are two main approaches for resolving this problem: approaches based on the calling client, and approaches based on a server or device of the communication network.
The first category notably includes the STUN (“Simple Traversal of UDP through NATs”) mechanism, described in RFC 3489. This mechanism allows a client (or terminal) to know its second address. In this manner, prior to a message being sent to the second communication network (for example, the public network), the calling client transmits a request to a STUN server located within this second network. This network replies with a message containing the address (and port) with which it “sees” the client, i.e. its second address.
The client may then use this second address to indicate, via the SDP protocol, which address it wishes to use[[s]] to receive replies.
However, this solution suffers from a major limitation, because numerous NAT devices are said to be “symmetrical” and bind a second address to a pair of parties. Additionally, the second address assigned to the client by the NAT device may be different for communication with the STUN server and for the session to be established with the other party. In a similar case, communication between the client and the other party cannot be established.
Other proposals, based on the same principle, have been made to improve the situation, such as TURN (“Traversal Using Relay NAT”) mechanisms.
However, neither the STUN mechanism nor the TURN mechanism is suitable for the SIP protocol.
Additionally, a new mechanism, ICE (“Interactive Connectivity Establishment”) has been proposed to make SIP signaling messages suitable for traversal. It is based on the STUN and TURN mechanisms, by adapting them.
The second category of solutions relies upon a device within the communication network. It should be noted that the earliest solutions implemented a server within the network (for example, a STUN server), but with the client having the initiative. In this second family of solutions, however, the initiative and implementation of NAT traversal solutions are both incumbent on a network device.
For example, a first solution belonging to this family is binding an application gateway to the NAT address translation device. This mechanism is known as ALG, for “Application Layer Gateway” or “Application-Level Gateway”, and is defined is paragraph 2.9 of RFC 2663, entitled “IP Network Address Translator (NAT) Terminology and Considerations”, published in August 1999.
This gateway (or a NAT device having the same functionalities of such a gateway) has means for understanding the application protocols used by the messages. In particular, it can understand the content of signaling messages, and translate the physical addresses contained within the SDP messages so that the parties may exchange their second addresses, rather than their first addresses, and may thereby establish communication sessions.
One variant of this solution consists of using a session controller, or SBC (for “Session Border Controller”), which will be located along the paths of the signaling messages. This type of product makes it possible to control the transmission of the communication sessions and signaling messages between both networks. More precisely, the SBC may play the role of an SIP “proxy” signaling element, which can control the means of transmitting media (a “media proxy”) via a protocol such as Megaco, so that the communication sessions may be suitably established between the parties.
However, another technical problem arises in that the NAT address translation devices do not save the bindings within the first and second addresses after the connection or session is terminated.
The SIP signaling messages may be transported by the TCP (Transmission Control Protocol) or UDP (User Datagram Protocol) protocol. The TCP protocol saves an open connection until an action is taken to terminate the session. Additionally, if an SIP session using TCP is used, the NAT address translation device will save the binding until the TCP connection is terminated.
However, for the UDP protocol, no connection is established. Additionally, the NAT address translation device only saves the binding temporarily, i.e. until a predetermined length of time has expired.
Consequently, the use of the UDP protocol to transport an SIP signal raises significant problems for NAT address translation device traversal.
However, using the TCP protocol also raises problems, in that it requires the various participants to save open connections. In such a case, the server or proxy must keep saved as many open connections as there are SIP terminals, or clients, with which it is communicating.
As each TCP connection represents a significant quantity of contextual data, this is a significant burden for the SIP proxy. The designer of a communication network may also find himself faced with very tangible problems, such as the maximum limit of TCP connections that an operating system such as Linux can handle (65536 simultaneous connections).
Additionally, the majority of SIP architectures are currently based on the UDP transport protocol.
In order to remedy the temporary nature of the bindings between the first and second addresses, signaling messages are periodically transmitted between both parties for the sole purpose of keeping the binding active.
These signaling messages are usually “Register” messages of the SIP protocol, which include an “Expires” header containing the expiration value of the binding. This expiration period may be negotiated between the client and the server or proxy. For example, in the first “Register” message, the client indicates a first value. The server or proxy replies with a “200 Ok” message containing a second value in the “Expires” header. In accordance with the standard, the client must then use this second value as the expiration period: it will then send a “Register” message at regular intervals determined by this second value.
This approach is known as “UDP Hole Punching”.
However, the TCP protocol has advantages which make it necessary for certain applications.
For example, when a message is large in size, the UDP protocol breaks it down into smaller datagrams, which may lead to fragmentation problems. The threshold is dependent on the communication network, and is determined by its maximum transmission unit (or MTU). This threshold is 1300 bytes for an Ethernet™ network.
As explained in paragraph 18.1.1. of RFC 3261, the UDP protocol may no longer be used once an SIP message has surpassed a size corresponding to this threshold minus a buffer value of 200 bytes. The TCP protocol (or another protocol enabling congestion control) must be used in such a case.
Consequently, neither the use of the UDP protocol nor of the TCP protocol is satisfactory, and there is a need for a solution that remedies the technical problems raised by both of the known solutions. The purpose of this invention is to propose such a solution.